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Under  Work  Unit  #  RSM-E1 


Regional  Sediment  Management  (RSM)  refers  to  the  effective  use  of  littoral,  estuarine,  and  river¬ 
ine  sediment  resources  in  an  environmentally  effective  and  economical  manner.  The  U.S.  Army 
Corps  of  Engineers  manages  lands  and  waterways  across  the  United  States.  The  Corps’  use  of 
RSM  concepts  will  significantly  improve  the  its  mission  accomplishment.  As  part  of  that  mission. 
Corps’  engineers  and  scientists  develop  new  technologies  to  make  management  decisions  more 
accurate  and  efficient.  Simultaneously,  they  evaluate  RSM  concepts  through  demonstration  pro¬ 
jects  that  highlight  and  improve  sediment  management  activities. 

This  phase  of  work  was  undertaken  to:  (1)  provide  guidelines,  technical  support,  and  planning  ap¬ 
proaches  for  researchers  that  result  in  realistic  life  cycle  plans  for  products  emerging  from  the 
RSM  research  program;  (2)  focus  the  RSM  program  community  of  interest  on  the  planned  out¬ 
comes  of  the  RSM  investment,  and  the  infusion  of  these  outcomes  into  District  operations; 

(3)  identify  and  resolve  barriers  to  successful  technology  infusion;  (4)  develop  approaches  and 
metrics  for  measuring  technology  infusion  success  and  processes  for  making  post-infusion  ad¬ 
justments  to  improve  this  success,  (5)  facilitate  successful  technology  transfer  beyond  USAGE. 
The  concepts  proposed  here  are  intended  to  improve  life  cycle  planning  from  USAGE  research  in¬ 
vestments. 
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Conversion  Factors 


Non-SI  units  of  measurement  used  in  this  report  can  be  converted  to  SI  units  as 
follows: 
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Systeme  International  d'Unites  (“International  System  of  Measurement”),  commonly  known  as  the  “metric  system. 
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1  Introduction 

Background 

Regional  Sediment  Management  (RSM)  refers  to  the  effective  use  of  littoral,  es¬ 
tuarine,  and  riverine  sediment  resources  in  an  environmentally  effective  and 
economical  manner.  RSM  strives  to  maintain  or  enhance  the  natural  exchange 
of  sediment  within  the  boundaries  of  the  physical  system.  RSM  changes  the  fo¬ 
cus  of  engineering  activities  within  the  coastal,  estuarine,  and  riverine  systems 
from  the  local,  or  project- specific  scale,  to  a  broader  scale  that  is  defined  by  the 
natural  sediment  processes  and  that  may  include  the  entire  watershed. 

Implementation  of  RSM  recognizes  that  the  physical  system  and  embedded  eco¬ 
systems  are  modified  and  respond  beyond  the  formal  dimensions  and  time 
frames  of  individual  projects.  As  a  management  method,  RSM: 

•  includes  the  entire  environment,  from  the  watershed  to  the  sea 

•  accounts  for  the  effect  of  human  activities  on  sediment  erosion  as  well  as  its 
transport  in  streams,  lakes,  bays,  and  oceans 

•  protects  and  enhances  the  nation’s  natural  resources  while  balancing  na¬ 
tional  security  and  economic  needs. 

RSM’s  larger  spatial  and  longer  temporal  perspectives,  combined  with  the  broad 
range  of  disciplines  with  a  stake  in  RSM  projects,  require  partnerships  with  and 
co-leadership  of  RSM  initiatives  by  the  stakeholders.  Decisions  concerning  the 
timing  and  scope  of  projects  that  move  or  utilize  sediment  must  be  made  within 
an  understanding  of  the  regional  system. 

The  U.S.  Army  Corps  of  Engineers  (USACE)  holds  in  trust  and  manages  lands 
and  waterways  across  the  United  States.  The  Corps’  use  of  RSM  concepts  will 
significantly  improve  the  its  mission  accomplishment.  As  part  of  that  mission, 
Corps’  engineers  and  scientists  develop  new  technologies  through  research  to 
make  management  decisions  more  accurate  and  efficient.  Simultaneously,  they 
evaluate  RSM  concepts  through  demonstration  projects  that  highlight  and  im¬ 
prove  sediment  management  activities. 
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Additionally,  The  U.S.  Army  Corps  of  Engineers  uses  Engineer  Regulation  (ER) 
5-1-11  as  its  business  process  guide.  This  ER,  which  establishes  philosophy, 
policy,  and  guidelines  to  accomplish  all  work  performed  by  the  U.S.  Army  Corps 
of  Engineers,  defines  the  Project  Management  Business  Process  (PMBP)  as: 

The  fundamental  USACE  business  process  used  to  deliver  quality  pro¬ 
jects.  It  reflects  the  USACE  corporate  commitment  to  provide  “customer 
service”  that  is  inclusive,  seamless,  flexible,  effective,  and  efficient.  It 
embodies  communication,  leadership,  systematic  and  coordinated  man¬ 
agement,  teamwork,  partnering,  effective  balancing  of  competing  de¬ 
mands,  and  primary  accountability  for  the  life  cycle  of  a  project,  (p  A2) 


The  regulation  also  stipulates  seven  imperatives  that  govern  the  PMBP  (p  2): 


ER  5-1-11 

USACE  Business  Process  Imperatives 

1.  One  project,  one  team,  one  project  manager 

2.  Plan  for  success  and  keep  commitments 

3.  The  Project  Delivery  Team  (PDT)  is  responsible  for  project  success 

4.  Measure  quality  with  the  goals  and  expectations  in  the  Project  Management  Plan  (PBP) 

5.  Manage  all  work  with  the  PMBP,  using  corporate  automated  information  systems  (AIS’s) 

6.  Build  effective  communications  into  all  activities  and  processes 

7.  Use  best  practices  and  seek  continuous  improvement 


The  RSM  Program,  a  new  (begun  FY02)  Civil  Works  research  initiative  focused 
on  providing  understanding  and  solutions  for  regional  management  of  sediment, 
is  one  of  the  three  recent  strategic  Civil  Works  R&D  initiatives.  Together  with 
Technologies  and  Operational  Innovations  for  Urban  Watershed  Networks 
(TOWNS),  and  the  System-Wide  Modeling,  Assessment,  and  Restoration  Tech¬ 
nologies  (SMART)  program,  the  RSM  Program  is  breaking  new  ground  in  pro¬ 
gram  development  and  execution. 

RSM  Program  sponsors,  proponents,  program  managers,  field  advisors,  and  in¬ 
vestigators  are  all  jointly  concerned  that  the  outcomes  from  this  research  pro¬ 
gram  provide  value  to  the  agency  and  to  others.  To  ensure  this  successful  out¬ 
come,  all  research  programs  need  to  address  product  life-cycle  planning.  This 


ER  5-1-11,  U.S.  Army  Corps  of  Engineers  Business  Process  Headquarters  (Headquarters,  U.S.  Army  Corps  of 
Engineers  [HQUSACE],  Washington,  DC,  17  August  2001). 
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work  was  undertaken  to  fill  that  program- development  need,  to  addresses  prod¬ 
uct  milestone  descriptions  and  definitions  of  research  outcomes  for  use  in  life  cy¬ 
cle  planning,  and  to  provide  direction  on  publications  and  technology  transfer 
planning. 


Objectives 

Overall  objectives  of  the  RSM  Program  are  to: 

1.  Provide  necessary  knowledge  and  enabling  technologies  that  will  lead  to  im¬ 
proved  capabilities  for  regional  sediment  management. 

2.  Provide  analytical  techniques  and  models  that  give  the  USACE  the  capability  to 
characterize  both  regional- scale  and  local-scale  project  sediment  impacts — 
sediment  yield,  transport  and  fate — and  to  evaluate  management  alternatives. 

3.  Provide  guidance  for  designing,  constructing,  operating,  and  maintaining  water 
resource  projects  to  effectively  manage  sediment  from  a  regional  perspective  and 
to  manage  individual  projects  within  the  context  of  regional  sediment  manage¬ 
ment  objectives. 

4.  Produce  an  information  and  knowledge  (informatics)  complete  with  data,  soft¬ 
ware  tools,  and  procedures  that  facilitate  effective  Corps  business  practices  and 
decisionmaking  in  regional  sediment  management. 

5.  Rapidly  and  effectively  transfer  the  products  from  this  program  to  Corps  of  Engi¬ 
neers  personnel,  insert  its  tools  into  Corps’  practices,  inform  and  be  informed  by 
stakeholders,  and  facilitate  mutually  beneficial  exchanges  with  other  organiza¬ 
tions. 

Specific  objectives  for  this  phase  of  work  were  to: 

1.  Provide  guidelines,  technical  support,  and  planning  approaches  for  researchers 
that  result  in  realistic  and  valuable  life  cycle  plans  for  products  emerging  from 
the  RSM  and  other  related  research  programs. 

2.  Focus  the  RSM  program  community  of  interest  (program  manager,  field  advisors, 
proponents,  collaborators,  investigators)  on  the  planned  outcomes  of  the  RSM  in¬ 
vestment,  and  the  issues  associated  with  successful  infusion  of  these  outcomes 
into  District  operations. 

3.  Identify  and  resolve  barriers  associated  with  successful  technology  infusion. 


Regional  Sediment  Management  Research  Program  (July  2002,  William  McAnally). 
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4.  Develop  approaches  and  metrics  for  measuring  technology  infusion  success  and 
processes  for  making  post- infusion  adjustments  to  improve  this  success. 

5.  Facilitate  successful  technology  transfer  beyond  USACE. 

Approach 

The  planning  effort  involved  coordination  of  a  “virtual  committee,”  which: 

1.  Identified  the  nature  and  type  of  planned  outcomes  from  the  RSM  research  pro¬ 
gram. 

2.  Developed  guidelines  to  move  planned  products  through  a  cycle  of  consistent 
steps  necessary  for  successful  technology  infusion.  This  involved  developing  the 
necessary  resources  and  procedures  to  facilitate  life  cycle  planning,  including: 

a.  A  product/milestones  database  for  RSM 

b.  Publication  templates  for  RSM 

c.  Post-infusion  metrics  and  analysis  tools 

d.  A  framework  for  learning  lessons  from  RSM  experiments  and  applica¬ 
tions. 

3.  Coordinated  these  guidelines  with  RSM  investigators,  proponents,  field  advisors 
and  other  stakeholders. 

4.  Outlined  steps  to  ensure  that  these  guidelines  reach  the  intended  investigators 
through  presentations,  workshops,  reviews,  web  services  and  other  mechanisms 
and  forums. 

Scope 

This  Product  Life  Cycle  Planning  effort  is  focused  primarily  on  the  technological 
outcomes  that  will  emerge  from  the  Regional  Sediment  Management  Research 
Program.  However,  this  investment  in  life  cycle  planning  will  directly  inform 
approaches  for  two  other  new  Civil  Works  research  programs:  System-wide 
Modeling,  Assessment,  and  Restoration  Technologies  (SMART),  and  Technolo¬ 
gies  and  Operational  Innovations  for  Urban  Watershed  Networks  (TOWNS).  In 
addition,  this  life  cycle  planning  approach  will  help  inform  all  other  military  and 
civil  research  programs  conducted  by  USACE  research  organizations. 


Mode  of  Technology  Transfer 

The  primary  focus  of  life  cycle  management  of  RSM  outcomes  is  to  facilitate  suc¬ 
cessful  technology  infusion  of  these  outcomes  into  operational  approaches  across 
the  Corps  of  Engineer  Districts.  Another  important  objective  for  life  cycle  plan- 
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ning  is  to  achieve  successful  transfer  of  technology  outcomes  to  the  scientific 
community  and  to  organizations  that  partner  with  or  work  independently  from 
the  Corps  of  Engineers. 

It  is  anticipated  that  the  outcomes  of  the  RSM  Program  (numerous  reports,  da¬ 
tabases,  models  or  model  enhancements,  workshops,  guidelines  and  other  out¬ 
comes  related  to  Program  objectives)  will  be  disseminated  through  published 
guidelines,  workshops,  web  services,  and  specific  tools  and  procedures  that  will 
be  delivered  directly  to  RSM  investigators  and  other  RSM  stakeholders.  This 
report  will  be  made  accessible  through  the  World  Wide  Web  (WWW)  at  URL: 

http://www.cecer.army.mil 
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2  Product  Life  Cycle  Process  Descriptions 

Introduction 

An  understanding  of  the  research,  development,  and  technology  transfer  process 
is  critical  for  those  organizations  and  individuals  involved  in  the  process.  The 
ultimate  goal  of  the  process  is  to  develop  and  field  technology  that  enables  the 
Army  customer  to  conduct  business  in  the  most  efficient  manner.  This  chapter 
describes  the  various  stages  of  the  technology  life-cycle  management  process  and 
identifies  the  responsibilities  for  the  various  organizations  involved  in  the  proc¬ 
ess.  The  process  (shown  in  Figure  1)  consists  of  these  phases: 

•  Requirements  generation  and  prioritization 

•  Assessment  and  selection  of  preferred  technology  solutions 

•  Technology  development 

•  Demonstration  and  validation 

•  Authorization/transition  planning 

•  Implementation 

•  Technology  evaluation 

•  Disposal. 


Phase  1:  Requirements  Generation  and  Prioritization 
Description 

The  Product  Life  Cycle  Process  begins  with  the  identification  of  critical  problems 
to  be  solved  through  research  activities.  The  objective  of  the  first  phase  of  prod¬ 
uct  life  cycle  planning  is  to  identify  a  prioritized  listing  of  problems  and  needs 
that  can  be  developed  into  requirements  documents  for  use  in  defining  the  re¬ 
search  and  development  activities  and  the  overall  technology  management  effort. 

Problems  and  needs  can  come  from  personnel  at  Headquarters,  Major  Army 
Commands,  laboratories,  Corps  Divisions  and  Districts,  and  installations  and 
other  users.  Technology  proponents  at  headquarters  can  work  with  field  review 
and  advisory  groups  to  review  submitted  problems  and  need  statements  and  pri¬ 
oritize  those  as  most  important  to  the  Army  at  large. 
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Figure  1.  Roles  and  responsibilities  pertaining  to  the  product  life-cycle  process. 


These  needs  should  be  considered  in  conjunction  with  broader  Army  and  organ¬ 
izational  objectives.  These  identified  and  prioritized  needs  should  be  written  up 
in  a  formal  requirements  document.  Technology  developers  use  these  require¬ 
ments  documents  to  develop  the  research  and  development  program.  In  some 
cases,  the  R&D  community  may  conduct  a  more  detailed  requirements  analysis 
to  further  define  these  requirements.  These  requirements  documents  should  be 
reviewed  and  updated  annually  by  the  proponents  working  with  the  representa¬ 
tives  of  field  organizations  (field  review  groups).  Table  1  lists  the  participants  in 
the  requirements  generation  process  and  their  responsibilities. 

Metrics 

•  Requirements  documents  have  been  revised  or  developed  based  on  an  up¬ 
dated  listing  of  prioritized  critical  needs. 

•  Authorization  is  granted  to  investigate  the  means  and  feasibility  of  resolving 
the  need. 
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Table  1.  Participants  and  their  responsibilities  in  the  requirements  generation  process. 


Participant 

Responsibilities 

Proponents 

•  Provide  a  top-down  perspective  on  future  technology  requirements  based  on  Army  and 
organizational  goals  and  strategies 

•  Regularly  solicit  input  from  end  users  on  critical  and  long  term  problems 

•  Conduct  meeting  of  field  review  groups  to  identify  and  prioritize  research  needs 

•  Use  input  from  field  review  groups  to  develop  requirements  documents 

Developers 

•  Collect  information  on  user  needs  for  use  in  developing  R&D  program 

•  Provide  input  to  field  review  groups  on  needs  based  on  their  contact  with  users 

•  Assist  proponents  in  development  and  documentation  of  requirements 

Users 

•  Assign  individuals  to  serve  as  technical  representatives  on  field  review  groups 

•  Provide  input  on  research  needs  to  proponents  and  field  review  groups 

Phase  2:  Assessment  and  Selection  of  Preferred  Technology  Solutions 
Description 

The  objectives  of  the  second  phase  of  product  life  cycle  planning  are  to:  (1)  de¬ 
velop  and  conduct  a  research  program  addressing  the  critical  needs  identified  in 
requirements  documents,  and  (2)  assist  developers  and  proponents  identify  the 
proposed  optimal  solution  to  the  need  or  problem.  This  phase  typically  starts 
with  some  type  of  technology  options  analysis.  During  this  analysis,  commercial 
technology  also  should  be  considered.  Information  provided  by  vendors  can  be 
reviewed  to  determine  the  benefits  and  uniqueness  of  the  technology.  In  this 
phase,  individual  research  efforts  are  established  to  identify  technical  solutions 
to  problems  identified  in  the  requirements  documents.  Proponents  and  occa¬ 
sionally  field  review  groups  will  provide  input  to  the  research  effort  to  assist  the 
developers  in  assessing  the  merits  of  alternatives  being  considered.  This  phase 
results  in  an  optimal  solution  to  the  identified  need  that  has  undergone  a  proof 
of  concept  test  or  is  generally  recognized  by  developers  and  proponents  to  be  an 
optimal  solution.  The  proposed  solution  will  be  technically  feasible.  Table  2  lists 
the  participants  in  the  identification  of  technology  solutions  and  their  responsi¬ 
bilities. 

Metrics 

•  Alternative  solutions  that  satisfy  the  need  were  considered.  The  organization 
via  the  proponents  is  committed  to  implement  the  proposed  solution  and  in¬ 
corporate  it  into  its  operations. 
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Table  2.  Participants  and  their  responsibilities  in  the  identification  of  technology  solutions 
process. 


Participant 

Responsibilities 

Proponents 

•  Conduct  meeting  of  field  review  groups  to  provide  input  on  proposed  technology 
solutions  developed  by  laboratories 

•  Provide  input  on  proposed  technology  solutions 

•  Define  business  practices  and  the  user  environment  in  which  the  technology  solution 
would  be  applied 

•  Provide  initial  commitment  to  support  the  transfer  and  fielding  of  proposed  technology 
solution 

Developers 

•  Develop  research  and  development  program  to  meet  critical  requirements 

•  Conduct  research  efforts  to  identify  alternatives  and  ultimately  the  optimal  solutions  to 
solving  specific  requirements 

•  Consider  the  use  of  commercial  technology  and  emerging  technology  trends  in  the 
alternatives  solutions 

•  Keep  proponents  informed  and  solicit  input  on  the  assessment  of  alternative  technology 
solutions 

•  Obtain  field  input  on  technology  options  via  field  review  groups  or  other  means 

•  Incorporate  technology  infusion  life-cycle  support  considerations  into  the  assessment  of 
alternatives 

•  Conduct  proof  of  concept  test  of  technology  as  appropriate 

•  Make  a  recommendation  to  lab  management  and  proponents  on  optimal  solution 

Users 

•  Participate  in  field  review  groups  to  provide  input  to  the  identification  and  assessment  of 
potential  technology  solutions 

•  Define  business  practices  and  the  user  environment  in  which  the  technology  solution 
would  be  applied 

Phase  3:  Technology  Development 
Description 

Once  the  optimal  solution  has  been  identified,  developers  will  focus  their  efforts 
on  developing  the  technology.  The  objectives  of  the  technology  development 
phase  of  product  life  cycle  planning  are  to:  (1)  develop  a  technology  solution  that 
is  technically  workable  as  proven  via  field  testing  and  (2)  develop  a  draft  tech¬ 
nology  infusion  plan  addressing  all  aspects  of  implementation  activities  includ¬ 
ing  funding.  If  a  commercial  technology  is  chosen  as  the  solution  to  the  stated 
requirement,  this  phase  may  be  bypassed.  Developers  and  proponents  will  en¬ 
sure  the  technology  will  be  interoperable  with  existing  legacy  systems  and  new 
systems  in  development.  Developers  will  work  with  proponents  and  users  to  en¬ 
sure  the  solution  will  fit  within  existing  business  practices  or  make  plans  to  ad¬ 
just  business  practices  based  on  the  technology  solution.  Special  emphasis 
should  be  directed  towards  how  the  technology  will  be  applied  by  potential  users. 
Draft  versions  of  user  manuals  or  some  form  of  user  training  aids  will  need  to  be 


10 


ERDC  SR-03-1 


developed  to  assist  users  during  pilot  tests  and  demonstrations.  At  this  point, 
initial  product  life  cycle  plans  will  be  developed  addressing  technology  transfer 
and  all  aspects  of  product  life  cycle  management.  These  plans  will  be  finalized 
later  in  the  authorization  and  transition  planning  phase. 

Some  technology  solutions  may  be  complicated  or  require  specialized  expertise  to 
run  such  as  in  the  case  of  some  models.  These  solutions  may  be  best  imple¬ 
mented  not  as  a  product  transferred  to  all  users,  but  as  a  capability  or  service 
provided  by  a  limited  number  of  providers.  These  providers  can  then  staff  up 
and  train  a  workforce  to  specialize  in  providing  that  technology  solution  to  users. 

Specialized  user  groups  or  project  delivery  teams  (PDTs)  can  be  established  to 
provide  input  in  the  development  of  the  technology,  the  system-user  interface, 
related  business  processes,  initial  training  materials,  and  technology  infusion 
plans.  Alpha  tests  will  be  conducted  to  ensure  the  technical  adequacy  of  the 
technology.  Table  3  lists  the  participants  in  the  technology  development  phase 
of  life  cycle  planning  and  their  responsibilities. 


Table  3.  Participants  and  their  responsibilities  in  technology  development  process. 


Participant 

Responsibilities 

Proponents 

•  Participate  in  project  delivery  teams  (PDTs)  as  appropriate 

•  Provide  input/decisions  on  business  practices  that  will  be  affected  or  need  to  be 
modified  based  on  the  implementation  of  the  technology 

•  Oversee  the  development  of  proposed  initial  technology  transfer  plan  covering  all 
aspects  of  the  implementation  activities 

Developers 

•  Conduct  developmental  research  to  create  the  technology  solution 

•  Ensure  the  technology  is  compatible  with  existing  or  future  Army  operations 

•  Conduct  user  groups  or  solicit  field  input  as  appropriate  to  guide  the  development 
of  the  technology  with  particular  emphasis  on  the  system-user  interface  and 
accompanying  business  Practices 

•  Assist  proponent  in  development  of  proposed  technology  transfer  plan 

•  Develop  draft  instructional  documents  to  assist  the  user  in  applying  the  technology 

•  Conduct  alpha  tests  of  the  developed  technology  and  draft  instructional 
documents  to  ensure  their  technical  adequacy 

Users 

•  Participate  in  user  groups  or  other  forums  to  provide  input  to  the  technology 
development  effort 

•  Provide  input  on  field  operations  and  business  practices  to  support  the  technology 
development 

•  Provide  input  on  system-user  interface  to  help  define  the  “look  and  feel”  of  the 
product 

•  Provide  input  to  the  proposed  technology  transfer  plan 
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Metrics 

•  Authorization  is  granted  to  execute  a  project  plan  that  produces  products  for 
a  product  suite  and  resolves  the  recognized  need.  (LP02,  LCMIS  II) 

•  All  components  of  the  project  are  designed.  The  design  supports  the  user’s 
published  technology  policy/requirements. 

•  The  operational  products  are  designed  to  interoperate  with  other  technolo¬ 
gies  in  use  in  the  user’s  environment. 

•  A  product  prototype  was  tested  in  a  controlled  environment  without  identify¬ 
ing  any  critical  deficiency  in  the  prototype.  This  is  the  successful  completion 
of  an  alpha  test. 

•  A  product  prototype  was  successfully  tested  in  an  environment  emulating  the 
user’s  environment.  The  technology  is  now  ready  for  demonstration/beta 
testing. 


Phase  4:  Demonstration  &  Validation 
Description 

The  field  demonstration/beta  test  is  a  key  element  in  the  overall  transfer  of  the 
technology.  The  objective  of  this  phase  of  product  life  cycle  planning  is  to  dem¬ 
onstrate  the  application  of  the  technology  in  a  real  life  setting  to  document  its 
cost  effectiveness  and  determine  operational  difficulties  encountered  by  users. 
The  demonstration/beta  test  is  the  first  attempt  to  show  the  effectiveness  of  the 
technology  to  users.  Unlike  the  proof  of  concept  and  alpha  tests,  which  are  in¬ 
tended  to  test  and  refine  the  technology,  the  demonstration/beta  test  focuses  on 
how  the  user  implements  and  benefits  from  the  technology.  A  successful  demon¬ 
stration/beta  test  will  produce  information  on  cost  of  implementation,  savings 
achieved  from  its  use,  and  operational  problems  facing  users  resulting  from  its 
implementation  and  use. 

The  demonstration  also  provides  an  opportunity  to  identify  the  effectiveness  of 
instructional  materials.  Table  4  lists  the  participants  in  the  technology  demon¬ 
stration  and  validation  phase  of  product  life  cycle  planning  and  their  responsi¬ 
bilities. 

Metrics 

•  The  product  has  completed  testing  in  the  user’s  environment  for  successful 
completion  of  the  beta  test. 

•  The  product  performs  adequately  in  the  user’s  environment  and  is  ready  for 
operation  in  the  user’s  operating  offices. 
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Table  4.  Participants  and  their  responsibilities  in  technology  demonstration  and  validation 
process. 


Participant 

Responsibilities 

Proponents 

•  Actively  seek  out  funding  or  opportunities  to  demonstrate/beta  tests  as  part  of  existing 
projects 

•  Provide  input  to  demonstration  site  selection 

•  Monitor  results  of  demonstrations  and  make  decision  on  readiness  of  the  technology  for 
implementation 

Developers 

•  Develop  appropriate  contractual  clauses  or  specifications  unique  to  the  technology  to 
assist  site  personnel  procure  and  apply  the  technology  at  the  demonstration  site 

•  Conduct  demonstrations  or  assist  in  applying  technologies 

•  Document  the  results  of  the  demonstration  with  an  emphasis  on  costs  and  benefits 

•  Identify  additional  training  requirements  that  may  be  needed  to  support  technology 
transfer 

Users 

•  Provide  input  and  assist  proponents  and  developers  in  lining  up  demonstration  sites 

•  Implement  the  technology  at  demonstration  sites  with  assistance  from  developers 

•  Assist  developers  in  documenting  benefits,  costs,  and  operational  issues  during  the 
demonstration/beta  test 

Phase  5:  Authorization/Transition  Planning 
Description 

Following  the  successful  completion  of  the  demonstration,  technology  proponent 
groups  will  work  with  headquarters  personnel  to  identify  and  authorize  tech¬ 
nologies  for  use  by  the  Army.  The  objectives  of  this  phase  of  product  life  cycle 
planning  are  to  finalize  the  technology  transfer  plan,  including  the  various  im¬ 
plementation  activities,  obtain  the  Army  commitment,  authorization,  and  fund¬ 
ing  necessary  to  implement  the  technology  and  the  technology  infusion  plan,  and 
mobilize  personnel  and  resources  to  implement  the  technology  infusion  plan. 
The  technology  transfer  plan  will  cover  all  aspects  of  the  implementation  plan¬ 
ning  activities — promotion,  packaging  and  distribution,  training,  user  support, 
and  funding.  Responsibilities  for  carrying  out  the  various  elements  of  the  tech¬ 
nology  transfer  plan  will  be  assigned  with  appropriate  funding  and  organiza¬ 
tional  support  as  needed.  Participants  may  include  developers,  user-based  cen¬ 
ters  of  expertise,  and  industry  and  academic  organizations.  Interim  guidance 
and  criteria  documents  will  be  prepared  to  authorize  use  of  the  technology  while 
formal  documents  are  being  updated.  Table  5  lists  the  participants  and  their  re¬ 
sponsibilities  in  the  authorization  and  transition  planning  phase  of  product  life 
cycle  planning. 
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Metrics 

•  Implementation  of  a  technology  can  occur  once  the  various  components  of  the 
implementation  mix  are  in  place  and  resourced. 

•  Organizations  having  responsibility  in  implementation  must  be  ready  to  ac¬ 
tively  assume  and  implement  those  responsibilities. 

Phase  6:  Implementation 
Description 

During  this  phase,  the  technology  transfer  plan  is  put  into  place.  The  objective 
of  this  stage  of  product  life  cycle  planning  is  to  distribute  and  encourage  the  use 
of  the  technology  Army-wide,  and  to  provide  follow-up  support  to  users.  Organi¬ 
zations  supporting  each  of  the  elements  in  the  technology  transfer  plan  are  car¬ 
rying  out  their  duties  in  support  of  users  implementing  the  technology.  Evalua¬ 
tions  of  the  technology  and  the  various  elements  of  the  technology  transfer  plan 
are  conducted  regularly  to  monitor  progress.  Critical  to  the  success  of  any  tech¬ 
nology  transfer  plan  are  the  provisions  for  training  and  support  to  users.  Table  6 
lists  the  participants  and  their  responsibilities  in  the  implementation  phase  of 
product  life  cycle  planning. 


Table  5.  Participants  and  their  responsibilities  in  authorization  and  transition  planning  process. 


Participant 

Responsibilities 

Proponents 

•  Finalize  technology  infusion  plan  that  covers  all  aspects  of  the  implementation  planning 
activities 

•  Identify  and  oversee  the  revision  of  Army  technical  documents  to  reflect  technology 

•  Assign  responsibilities  and  monitor  actions  for  carrying  out  the  various  components  of  the 
technology  infusion  plan 

•  Identify  sources  of  funding  to  support  development  of  technology  transfer  plans  and  later 
implementation  activities 

Developers 

•  Develop  appropriate  contractual  clauses  to  assist  users  in  obtaining  technology 

•  Assist  proponents  in  developing  and  carrying  out  activities  within  the  technology  infusion 
plans 

•  Develop  input  to  revisions  of  Army  technical  documents  under  direction  of  proponents 

Users 

•  Participate  in  field  review  groups  to  provide  input  to  the  technology  infusion  plans 

•  Serve  as  champions  to  encourage  the  use  of  the  technology  within  their  organizations 

•  Identify  funding  sources  and  mechanisms  within  organizations  to  support  technology 
transfer 
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Table  6.  Participants  and  their  responsibilities  in  implementation  process. 


Participant 

Responsibilities 

Proponents 

•  Oversee  the  implementation  of  the  technology  and  the  activities  of  the  various 
organizations  involved  in  implementing  elements  of  the  technology  transfer  plan 

•  Ensure  that  interim  technical  guidance  is  eventually  replaced  by  the  revision  of  more 
formal  Army  technical  documents 

•  Coordinate  technology  transfer  implementation  activities  among 

USACE/Army/contractor  organizations 

•  Ensure  technology  transfer  activities  are  adequately  funded 

Developers 

•  Assist  the  proponents  and  designated  technology  support  agents  in  assisting  users  as 
required  by  the  technology  transfer  plan 

•  Implement  technical  support,  training,  promotional  efforts  supporting  field  use  of  the 
technology 

Users 

•  Become  a  champion  for  local  implementation  of  the  technology  transfer  plan 

•  Identify  organizational  resources  and  personnel  to  assist  in  the  infusion  of  the  product 

Metrics 

•  The  product  has  been  infused  successfully  into  all  the  user’s  locations. 

•  The  product  is  in  routine  use  in  support  of  user  business  operations. 


Phase  7:  Evaluation 
Description 

The  objective  of  this  phase  of  product  life  cycle  planning  is  to  identify  needed  im¬ 
provements  in  the  technology  and  support  activities  via  periodic  assessments  of 
technology  use  and  support  activities.  Evaluations  of  the  success  of  the  technol¬ 
ogy  and  technology  transfer  plan  over  the  long  term  may  result  in  further  modi¬ 
fications  to  the  technology  and  technology  transfer  strategies.  The  technology 
may  once  again  go  through  some  or  all  phases  of  the  product  life-cycle  technology 
management  process.  (The  red  arrow  in  Figure  1  [p7]  shows  how  the  evaluation 
activity  may  conceptually  lead  back  to  Phase  1.)  Evaluations  may  also  identify 
deficiencies  in  existing  support  activities  or  documentation  that  need  to  be  ad¬ 
dressed.  Input  from  these  evaluations  may  lead  to  new  technology  requirements 
that  will  result  in  the  current  technology  being  replaced.  Furthermore,  an 
evaluation  may  lead  to  a  recommendation  to  eliminate  a  technology,  for  example, 
if  the  technology  has  become  obsolete,  if  it  is  no  longer  cost  effective  to  maintain 
the  technology,  or  if  the  function  it  supports  is  no  longer  required.  Table  7  lists 
the  participants  and  their  responsibilities  in  the  evaluation  phase  of  product  life 
cycle  planning. 
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Table  7.  Participants  and  their  responsibilities  in  evaluation  process. 


Participant 

Responsibilities 

Proponents 

•  Provide  oversight  to  technology  support  activities  to  ensure  they  are  effectively 
supporting  the  use  of  the  technology  in  the  field 

•  Periodically  monitor  use  of  the  technology  to  evaluate  long-term  success  of  the  various 
elements  of  the  technology  transfer  plan  and  modify  the  activities  as  appropriate 

•  Obtain  input  from  the  field  via  user  groups  or  other  evaluation  techniques 

Developers 

•  Periodically  gather  feedback  for  proponent  on  the  effectiveness  of  the  technology 

•  Monitor  use  of  the  technology  and  user  inquiries  to  identify  problems  with  field  use  of 
the  technology  and  to  propose  future  modifications 

•  Evaluate  effectiveness  of  promotional  materials,  training  efforts,  and  other  user 
documents  and  make  recommendations  to  modify  as  needed 

Users 

•  Provide  feedback  to  proponents  on  the  effectiveness  of  the  technology  and  the 
technology  transfer  activities 

Metrics 

•  The  product  may  require  changes  to  maintain  operation  capability.  Changes 
may  be  due  to  changes  in  technology,  policy,  business  process  or  law. 

•  The  product  is  no  longer  needed  in  the  user’s  environment  and  needs  to  be 
removed  from  the  operational  architecture. 

Phase  8:  Technology  Replacement  /  Reduction 
Description 

Products  at  some  point  will  need  to  be  replaced  by  new  or  alternate  technologies. 
The  objective  of  this  stage  of  product  life  cycle  planning  is  to  efficiently  remove 
the  product  from  use  with  minimal  impact  on  existing  business  processes  and 
operations.  The  disposal  process  includes  the  decision  to  dispose  of  the  product, 
transition  it  from  the  software  inventory,  and  business  practices  to  operate  with¬ 
out  it  or  to  operate  with  its  replacement.  Table  8  lists  the  participants  and  their 
responsibilities  in  the  disposal  phase  of  product  life  cycle  planning. 

Metrics 

•  The  product’s  replacement  is  identified  and  the  enterprise  has  committed  to 
implementing  the  replacement  product. 

•  The  product  has  been  removed  from  the  operational  environment. 
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Table  8.  Participants  and  their  responsibilities  in  disposal  process. 


Participant 

Responsibilities 

Proponents 

•  Make  decision  to  dispose  of  technology  as  a  result  of  input  on  new  technology 
developments,  availability  of  replacement  products,  etc. 

•  Develop  a  disposal  strategy  that  minimizes  impact  on  existing  field  operations 

Developers 

•  Support  disposal  activities  in  support  of  proponent  product  disposal  strategy 

•  Enable  data  conversions  to  new  software 

•  Enable  continuity  of  operations  for  users  during  transition  of  new  software 

•  Identify  impacts  to  operation  related  to  removing  the  product  from  the  software 
inventory 

Users 

•  Provide  input  to  proponents  on  disposal  strategy 

•  Support  implementation  of  disposal  activities 

Project  Delivery  Teams  and  Product  Life  Cycle  Planning 

User  input  to  the  product  life  cycle  planning  process  is  critical  to  the  successful 
transition  of  the  product  into  use.  Project  Delivery  Teams  (PDTs)  should  be  de¬ 
veloped  to  develop  the  product  plan  for  a  preferred  technology  solution.  The 
product  plan  includes  the  approach  for  product  design  and  development;  testing, 
evaluation,  and  approval;  technology  infusion;  and  the  post-infusion  analysis. 
Each  PDT  should  consist  of  a  representative  mix  of  proponents,  developers,  and 
users.  Each  member  will  provide  their  unique  perspective  into  the  development 
and  delivery  of  the  preferred  technology  solution.  The  PDT  will  then  assist  the 
proponent  in  the  eventual  transfer  of  the  technology  into  use. 

This  technology  transfer  requires  a  common  terminology  to  define  and  describe 
the  outcomes  of  each  phase,  and  the  preparations  for  the  next  phase.  A  common 
terminology  will  help  to  clarify  the  process  to  all  its  participants,  through  all  the 
phases,  and  help  to  successfully  transition  the  process  “between  phases.”  Chap¬ 
ter  3  defines  and  describes  the  terminology  governing  research  outcomes,  which 
will  ultimately  be  used  to  formulate  technology  development  and  technology 
transfer  plans. 
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3  Definitions  of  Research  and 
Technology  Outcomes 


“Outcomes”  are  categorized  here  as  outcomes  either  for  developers/proponent  or 
for  users/consumers.  This  information  will  be  used  in  developing  technology  de¬ 
velopment  plans  and  subsequent  technology  transfer  plans.  Consistent  use  of 
these  terms  will  facilitate  communication  among  technology  proponents,  end  us¬ 
ers,  and  other  researchers.  This  Chapter  defines  and  categorizes  research  out¬ 
comes  or  milestones  from  (as  a  working  example)  various  RSM  work  units.  The 
outcomes  are  categorized  by  who  will  use  them  and  by  how  the  various  outcomes 
from  each  work  unit  will  contribute  to  the  ultimate  product  or  capability  pro¬ 
vided  to  the  end  users. 


Outcomes  for  Developers/Proponents 

Scoping  Results 

Requirements  Assessment 

The  purpose  of  requirements  assessment  is  to  clarify,  magnify,  and  (if  possible) 
quantify  a  requirement  or  opportunity.  This  requirements  scoping  is  the  most 
critical  scoping  effort  because  the  outcomes  of  these  efforts  drive  the  R&D  in¬ 
vestment  strategies.  The  product  of  this  effort  is  a  report  with  recommendations 
(preferable  with  options)  for  future  investments.  Recommended  R&D  invest¬ 
ments  could  include  meeting  a  specific  product  requirement,  doing  research  to 
address  specific  unknown  processes,  gathering  an  existing  knowledge  base  into 
some  accessible/deliverable  format,  or  creating  a  suite  of  investments  that  com¬ 
prise  an  entire  “program.”  The  scoping  work  is  conducted  by  senior  R&D  and 
user  representatives.  This  type  of  scoping  effort  is  not  primarily  focused  on  de¬ 
tailed  analysis  of  life  cycle  costs — rather  it  is  focused  on  characterizing  a  re¬ 
quirement  and  considering  multiple  options  and  priorities  to  address  this  re¬ 
quirement.  These  scoping  efforts  should  also  consider  life-cycle  implications. 
Three  important  outcomes  from  these  requirements  assessment  are:  (1)  a  clear 
statement  of  the  initial  requirement,  which  has  been  reviewed  by  a  team  of  us¬ 
ers,  technology  developers,  and  proponents,  (2)  a  “use  case”  statement  that  de¬ 
scribes  how  the  desired  outcome  from  this  requirement  will  be  used,  and  (3)  met- 
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rics  to  measure  the  extent  to  which  the  desired  outcomes  meets  the  requirements 
objective  (e.g.,  reduces  cost  or  time  for  an  operation,  increases  organizational 
capability,  improves  decisions,  etc.). 

Technology  Options  Assessment 

A  “Technology  Options  Analysis”  is  appropriate  after  a  requirements  scoping  ef¬ 
fort  is  complete.  At  this  point  multiple  technology  solutions  might  be  considered 
to  meet  a  requirement.  This  assessment  will  result  in  a  decision  regarding  spe¬ 
cific  actions  to  undertake  to  achieve  desired  (and  well  described)  research  or 
product  outcomes.  Creative  alternative  solutions  should  keep  a  strong  focus  on 
the  outcome  and  consider  the  life  cycle  implications  of  this  outcome.  This  allows 
the  developer  to  anticipate  and  plan  various  coordination  issues  as  early  as  pos¬ 
sible.  At  this  stage  of  an  effort,  however,  these  is  still  risk  and  uncertainty,  so 
this  assessment  should  not  “lock  in”  these  resources;  rather,  it  should  create 
placeholders  that  get  reviewed  as  the  effort  progresses.  This  approach  scoping 
effort  is  primarily  the  responsibility  of  the  tech  developer/proposer,  with  in¬ 
volvement  from  the  user  proponent  and  representatives. 

Product  Plan  Development 

“Product  Plan  Development”  is  developing  a  detailed  product  life  cycle  plan  for  a 
preferred  technology  solution  identified  in  the  technology  options  assessment. 
The  product  plan  includes  the  approach  for  product  design  and  development; 
testing,  evaluation,  and  approval;  technology  infusion;  and  the  post-infusion  as¬ 
sessment.  At  this  point,  uncertainty  and  risk  in  terms  of  the  R&D  outcome 
should  be  minimal.  The  product  plan  goes  well  beyond  the  technology  options 
assessment  because  it  involves  the  transition  from  “placeholders”  to  “locked” 
scheduling  and  budgeting  actions.  All  the  issues  associated  with  moving  a  tech¬ 
nology  into  the  field  need  to  be  detailed,  risks  need  to  be  identified  and  ad¬ 
dressed,  and  various  infusion  options  must  be  considered.  Budget  and  schedule 
constraints  (or  opportunities)  may  require  adjustments  to  the  plans  approved  as 
a  result  of  the  approach  scoping  recommendations.  This  scoping  effort  needs  to 
be  led  by  the  proponents  and  users,  with  assistance  from  the  tech  developers. 

Research  Results 

Research  results  are  defined  here  as  the  outcomes  of  the  research  activities  that 
contribute  to  the  further  expansion  of  scientific  knowledge  or  the  continuing  de¬ 
velopment  of  a  product  or  capability  to  be  used  by  end  users  (Figure  3).  The 
primary  audience  and  user  of  research  results  are  other  researchers  and  devel¬ 
opers  who  will  use  the  outcomes  to  further  enhance  or  develop  a  product  or  con- 
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duct  additional  research.  The  non-research  consumer  will  unlikely  “touch  and 
feel”  a  research  result,  although  they  may  review  and  benefit  from  research 
knowledge  disseminated  via  published  information  exchange  efforts. 

Information  Generation 

“Information  generation”  refers  to  the  activities  and  investigations  leading  to  a 
further  understanding  of  scientific  and  engineering  principles  and  processes. 
These  include  activities  such  as  literature  reviews,  scientific  symposia  and  work¬ 
shops  to  solicit  information,  data  collection  in  laboratory  and  field  settings,  and 
scientific  and  technical  analyses. 

Component  Development 

“Component  development”  is  the  production  of  some  element  that  will  contribute 
to  the  further  development  of  the  final  product  to  be  fielded  to  the  actual  user  of 
the  technology.  A  component  could  include  an  algorithm  to  be  used  in  a  model,  a 
model  concept  or  framework  for  development  into  a  prototype  model,  end  user 
visualization  schema  for  the  user  interface  to  a  program,  or  program  code  to 
speed  the  processing  of  information  within  a  software  program. 

Information  Exchange 

“Information  exchange”  is  defined  as  documenting  and  communicating  the  re¬ 
sults  of  the  research  activities  to  other  researchers  and  developers.  Information 
exchange  is  conducted  via  research  reports,  articles  in  peer-reviewed  journals, 
and  papers  presented  at  technical  symposia  attended  by  researchers. 

Process  Milestone 

An  interim  step  in  the  research  and  development  process  that  contributes  to  the 
ultimate  result  of  the  research,  but  does  not  in  itself  generate  knowledge  or  re¬ 
sult  in  a  component  is  defined  as  a  “process  milestone.”  This  includes  such  ac¬ 
tivities  as  developing  a  survey  instrument,  letting  a  contract,  constructing  a 
physical  model,  or  procuring  instrumentation  or  software  to  support  the  research 
effort.  Process  milestones  will  occur  under  all  outcome  categories. 

Prototype 

A  prototype  is  an  initial  version  of  the  product  or  product  enhancement.  A  proto¬ 
type  would  be  used  by  developers  to  more  fully  test,  develop,  and  refine  the  tech¬ 
nology  concept.  Users/consumers  would  not  implement  a  prototype  on  their  own. 
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Figure  2.  Guidance  for  further  classification  of  research  results  and  products. 


Outcomes  for  Users/Consumers  (Products) 

Product  “outcomes”  are  developed  for  end  users  or  consumers  at  Army  installa¬ 
tions,  engineer  units,  and/or  Districts  and  Divisions,  and  non-DOD  consumers. 
Consumers  can  actually  “touch  and  feel”  a  product.  In  a  true  commercial  sense, 
a  product  would  be  a  “shrink  wrapped-like”  capability  provided  to  the  consumer 
that  is  implemented  to  support  their  daily  operations.  A  product  could  be  soft¬ 
ware,  hardware,  or  some  innovative  procedure  that  provides  the  consumer  with 
a  new  capability  to  support  his  or  her  daily  operations.  The  user  should  be  able 
to  implement  a  product  with  minimum  hands-on  assistance  by  the  technology 
developers. 

Some  outcomes  would  be  provided  as  a  technology  service  to  users  on  a  reim¬ 
bursable  basis  via  the  ERDC  or  other  technical  centers  within  the  Army  or  in¬ 
dustry.  The  outcomes  for  users/consumers,  defined  below,  also  include  the  types 
of  activities  necessary  to  effectively  transfer  the  product  to  the  field.  These 
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product  transition  activities  will  support  the  infusion  of  the  product  or  product 
enhancement  to  the  users. 

Product  Types 

New  Product 

A  “new  product”  is  exactly  what  the  name  implies,  a  completely  new,  never- 
before-provided  product  that  would  be  implemented  by  the  user  with  minimum 
assistance  from  the  developers. 

Product  Enhancement 

A  “product  enhancement”  differs  from  a  refinement  to  an  existing  product  in  that 
it  enhances  its  capability  to  users.  Product  enhancements  would  include  the  in¬ 
troduction  of  a  new  version  of  a  software  program,  addition  of  a  GIS  module  to 
an  existing  product,  or  modification  of  an  existing  software  program  to  include  a 
new  algorithm  or  function.  A  product  enhancement  differs  from  a  component 
described  under  “research  results”  in  that  the  enhancement  is  actually  used  by 
the  field  user.  The  component,  by  contrast,  is  embedded  in  the  product,  and  is 
not  visible  to  the  field  user.  The  enhancement  provides  additional  product  capa¬ 
bilities  that  will  improve  the  ability  of  the  field  user  to  perform  their  job. 

Capabiiity/Service 

The  implementation  of  some  outcomes  may  require  specialized  expertise  or 
knowledge  not  commonly  found  in  field  offices.  It  may  be  more  efficient  to  train 
a  few  individuals  to  provide  these  specialized  services  to  users  on  a  reimbursable 
basis.  These  technology  services  may  be  provided  via  ERDC  labs  or  centers  of 
technical  support  in  designated  Army  offices  or  industry.  This  would  differ  from 
a  support  center  for  a  product  or  product  enhancement  in  that  the  user/consumer 
would  actually  implement  the  product  with  only  minor  assistance  from  the  sup¬ 
port  center. 

Product  Transition 

Product  Documentation 

Development  of  documentation  will  assist  the  user  in  implementing  or  authoriz¬ 
ing  the  use  of  a  technology  product.  Typical  documentation  consists  of  instruc¬ 
tional  materials,  guide  specifications,  user  manuals,  technical  manuals,  or  other 
types  of  guidance  materials. 
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Promotion 

Promotional  activities  are  designed  to  inform  and  motivate  potential  users  to 
procure  and  implement  a  technology.  These  activities  will:  (1)  generate  an 
awareness  of  the  existence  of  a  technology  among  potential  users,  (2)  provide  in¬ 
formation  on  its  uses  and  benefits,  and  (3)  identify  procedures  and  sources  of  as¬ 
sistance  in  obtaining  the  technology  and  related  services.  This  would  include 
developing  fact  sheets,  brochures,  and  promotional  videos;  presentations  before 
users,  and  writing  articles  for  trade  and  user  publications. 

Training 

Instructional  materials  are  developed  to  help  users  apply  the  product  technology. 
This  would  include  self-instructional  materials  such  as  start-up  guides  and  user 
manuals  to  help  the  user  begin  applying  the  technology  on  a  limited  basis.  Ad¬ 
vanced  training  may  be  developed  to  further  the  user’s  knowledge  of  the  more 
specific  applications  of  the  technology.  Special  training  courses  may  also  be  de¬ 
veloped  for  different  types  of  users  of  the  same  technology.  Online  learning  and 
remote  training  via  the  internet  are  alternatives  to  traditional  classroom  learn¬ 
ing. 


User  Support 

Users  will  likely  have  questions  or  need  some  type  of  assistance  in  implementing 
a  technology.  Some  organization  or  individual  will  need  to  be  readily  available 
to  help  with  technology  problems  via  phone  or  e-mail,  and  to  provide  users  with 
updates  or  new  product  information.  Chat  rooms  or  online  support  centers  via 
listservers  and  groups  on  the  internet  are  e-commerce  business  practices  that 
could  also  be  considered. 

Packaging/Distribution 

“Packaging/distribution”  refers  to  those  activities  that  prepare  and  deliver  the 
technology  to  the  user.  Packaging  refers  to  how  the  technology  will  be  assembled 
for  distribution  to  the  user.  Distribution  refers  to  the  logistics  of  getting  a  tech¬ 
nology  from  a  provider  of  the  technology  to  a  user.  The  Internet  has  now  become 
a  major  medium  to  distribute  software  and  software  documentation. 
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Example  Preliminary  Research  Outcome  Analysis  for  RSM 

RSM  research  outcomes  were  input  into  a  spreadsheet  framework  and  classified 
into  categories  (described  above).  The  objective  of  the  outcome  analysis  was  to 
verify  that  research  program  outcomes  fit  into  definitions  for  the  different  types 
of  outcomes  and  the  purpose  for  which  they  would  be  used;  to  develop  a  proto¬ 
type  database  for  reporting  to  managers  and  others  basic  information  about  the 
program  outcomes;  and  to  assist  in  technology  transfer  plan  development  for 
product  lines. 

To  accomplish  this  classification  effort,  RSM  research  outcomes  (termed  “mile¬ 
stones”  in  PROMIS)  were  extracted  from  PROMIS  PPDS  reports  and  input  into 
a  spreadsheet  framework.  All  milestones  listed  for  individual  work  units  within 
the  program  were  considered  as  outcomes.  Available  milestone  information,  in¬ 
cluding  the  description  and  scheduled  completion  date  were  input  into  an  Excel 
spreadsheet.  These  milestone  “outcomes”  were  then  identified  as  specific  types 
such  as  “Technical  Report”  or  “Numerical  Model”;  designated  either  a  research 
result  or  product;  and  then  further  subcategorized  by  purpose  to  establish  the 
reasons  for  which  they  would  be  used. 

Once  the  outcomes  were  categorized  in  this  manner,  a  simple  analysis  was  con¬ 
ducted  to  provide  an  overview  of  the  outcome  database.  Totals  of  research  re¬ 
sults  and  products  were  calculated  by  purpose,  Work  Unit,  and  milestone  type 
(Tables  9,  10,  11).  Also,  all  publication  types  were  separated  from  the  milestone 
type  list  and  consolidated  in  Table  12. 

The  process  to  categorize  program  outcomes  from  the  PPDS  reports  was  based 
on  interpretations  from  milestone  lists  and  “Approach”  descriptions.  All  parts  of 
the  PPDS  reports  were  thoroughly  reviewed  to  interpret  the  tasks  from  other 
sections  in  the  documentation  and  place  the  tasks/products  in  the  appropriate 
outcome  categories  and  purpose.  Reviews  of  the  PPDS  reports  revealed  that  few, 
if  any,  tasks  were  defined  in  the  Primary  Task/Product  list.  In  many  of  the  RSM 
work  units,  the  list  of  primary  tasks/products  included  only  publications,  which 
were  all  indicated  as  products  in  PROMIS.  In  cases  where  some  tasks  were 
listed  as  Primary  Tasks,  other  obvious  tasks  were  omitted.  Additionally,  the 
documentation  did  not  define  who  would  receive  the  outcomes,  and  were  not  or¬ 
ganized  in  terms  of  life  cycle  phases  (planning,  development,  implementation, 
technology  transfer).  Therefore,  parts  of  this  analysis  were  subject  to  interpreta¬ 
tion.  Interpretations  proved  difficult  because  of  inconsistent  and  sometimes  in¬ 
complete  organization  and  development  of  the  Primary  Tasks/Products  section. 
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Table  9.  RSM  outcomes  from  documentation. 


Purpose 

Total* 

Research  Results 

Component 

17 

Information  Exchange 

56 

Knowledge  Generation 

23 

Process  Milestone 

9 

Total 

105 

New  Product 

2 

C/3 

Packaging/Distribution 

2 

O 

=3 

Product  Documentation 

17 

2 

Product  Enhancement 

9 

Product  Promotion 

9 

Total 

39 

‘Total  no.  of  outcomes  (Research  Results  +  Products)  =  144 

Table  10.  RSM  outcomes  by  work  units. 


Work  Unit 

Work  Unit  Title 

Research 

Results 

Products 

Total 

A1 

Geomorphic  response  of  regional  sediment  systems 

9 

0 

9 

A3 

Sand  transport  during  high  energy  events 

6 

0 

6 

A4 

Mixing  and  deformation  of  alluvial  bed  surfaces 

4 

4 

8 

A5 

Spatial  and  temporal  transport  processes  in  system 
context 

2 

2 

4 

A6 

Freeze-thaw  effects  on  soil  and  bank  erosion  and 
stability 

4 

3 

7 

A7 

Effects  of  organics  on  fine  sediment  beds 

8 

0 

8 

B1 

Regional  morphology  model 

6 

0 

6 

B2 

Overland  flow,  transport,  and  morphology  model 

3 

5 

8 

B3 

Multi-dimensional  sediment  model 

1 

8 

9 

Cl 

Integration  of  engineered  solutions 

8 

0 

8 

C2 

Measuring  and  monitoring  at  large  scales 

7 

0 

7 

C3 

Measuring  and  monitoring  at  local  scales 

7 

7 

14 

C4 

Morphologic  response  test  bed  database 

9 

1 

10 

D1 

Database  tools  for  data  storage  and  mining 

8 

2 

10 

D2 

Multi-level  analysis  framework 

6 

1 

7 

D3 

Graphical  user  environment  to  support  multi¬ 
dimensional  sediment  models 

3 

1 

4 

El 

Product  life  cycle  planning 

9 

0 

9 

E2 

Technology  transfer  services 

5 

5 

10 

Totals 

105 

39 

144 
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Table  11.  RSM  outcomes  by  milestone  type. 


Research  Results 

Products 

Category* 

Total 

Category* 

Total 

Algorithm 

3 

Briefing  Materials 

1 

Algorithm  Application 

1 

Brochure 

1 

Algorithm  Testing 

1 

Data  Warehouse 

1 

Analysis 

11 

Database 

1 

Catalog 

1 

Engineering  Manual  (EM) 

2 

Conference/Workshop  Paper 

2 

Exhibit 

1 

Database 

3 

Information  Update 

2 

Database  Design 

1 

Interagency  Guidelines 

1 

Equations 

1 

Journal  Paper  (JP) 

5 

Framework  revision 

1 

Model 

4 

Guidelines 

1 

Model  Revision 

3 

Information  Update 

1 

Model  Testing 

1 

Interface 

1 

Newsletter 

1 

Journal  Paper  (JP) 

9 

Technical  Note  (TN) 

2 

Metrics 

1 

Technical  Report  (TR) 

6 

Model  (Framework) 

1 

TR  Sections 

1 

Model  (Conceptual) 

4 

User’s  Manual 

2 

Plan 

2 

Website 

2 

Security 

1 

Total 

39 

Site  Selection 

1 

*  Total  number  of  categories  =  1 8 

Team 

4 

Template 

1 

Technical  Note  (TN) 

32 

Tool 

1 

Tool  Adaptation 

1 

Tool  Design 

11 

Technical  Report  (TR) 

1 

Workshop 

8 

Total 

105 

*  Total  number  of  categories  =  28 
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Table  12.  RSM  publication  outcomes. 


Publications 

Research  Results 

Products 

Total 

Engineering  Manual  (EM) 

0 

2 

2 

Journal  Paper  (JP) 

9 

5 

14 

Technical  Note  (TN) 

32 

2 

34 

Technical  Report  (TR) 

1 

6 

7 

Technical  Report  sections 

0 

1 

1 

User’s  Manual 

2 

2 

4 

Conference/Workshop  Paper 

2 

0 

2 

Total 

44 

18 

64 

Note:  Publications  constitute  approximately  44  %  of  all  RSM  Outcomes,  and  44 
and  46  %  of  Deliverables  and  Products,  respectively 

The  task/product  development  areas  in  the  RSM  Program  documentation  varied 
because  Principal  Investigators  (Pis)  had  insufficient,  incomplete,  or  no  corpo¬ 
rate  guidance  related  to  research  outcomes  (milestone  development)  definitions, 
life  cycle  phases.  Pis  are  the  primary  developers  of  program  documentation,  and 
typically  prepare  the  documentation  using  past  experience,  such  as  listing  only 
publications  as  products 

Despite  the  difficulties  in  locating  the  appropriate  milestones  and  in  interpreta¬ 
tion,  the  preliminary  outcome  analysis  resulted  in  verifying  that  research  pro¬ 
gram  outcomes  do  fit  into  the  business  categories  and  purposes  and  provided  ba¬ 
sic  information  that  proved  valuable  to  the  program  manager.  Suggestions  to 
obtain  more  accurate  information  about  research  program  outcomes  include: 

•  Providing  Pis  with  guidance  or  templates  for  developing  clear  definitions  of 
research  program  outcomes  such  as  those  provided  in  this  report.  Figure  2, 
which  shows  an  outline  that  uses  these  business  definitions,  illustrates  a  de¬ 
cisionmaking  model  to  help  Pis  develop  their  research  outcomes  in  the  con¬ 
text  of  life  cycle  engineering. 

•  Revise  PROMIS  documentation  to  reflect  new  outcome  categories  and  pur¬ 
poses 

•  Develop  a  reporting  system  within  PROMIS  using  the  outcome  analysis 
framework. 

Benefits  gained  from  analyzing  the  research  program  include: 

•  providing  RSM  proponents  and  users  with  overall  program  results  in  an  un¬ 
derstandable  and  uniform  format  (tables  and  charts) 

•  providing  RSM  managers  with  program  outcomes  to  improve  decision  mak¬ 
ing  at  the  program  and  work  unit  levels 

•  determining  gaps  in  the  life  cycle  process  (i.e.,  product  without  supporting 
documentation  or  technology  transfer  mechanisms). 
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Relationships  Between  Outcomes 

One  of  the  benefits  of  the  Product  Life  Cycle  Planning  approach  is  to  identify  and 
plan  for  the  relationships  between  outcome  types.  Major  product  or  capabil¬ 
ity/service  outcomes  may  involve  voluminous  information  generation,  informa¬ 
tion  exchange,  and  component  and  prototype  outcomes — all  necessary  work  that 
builds  towards  a  desired  product  outcome.  The  product  outcome  is  then  followed 
by  numerous  efforts  (technology  validation,  documentation,  and  implementation 
planning)  required  for  successful  technology  infusion. 

Communicating  and  examining  these  outcome  relationships  is  a  critical  step  in 
the  Product  Life  Cycle  Planning  approach.  Graphical  and  narrative  views  of 
outcome  relationships  provide  the  Project  Delivery  Team  with  a  context  to  look 
across  the  life  cycle  process  and  ensure  that  all  necessary  transitions  are  identi¬ 
fied,  planned,  scheduled,  and  resourced.  These  outcome  relationship  views  also 
provide  an  essential  form  for  communicating  plans  to  stakeholders  in  the  proc¬ 
ess. 

Figure  3  shows  a  “notional”  set  of  outcome  relationships  in  the  RSM  program. 
This  conceptual  framework  for  outcome  relationships  is  not  drawn  from  actual 
data  from  RSM  efforts — but  is  conceptually  close  to  outcome  relationships  of 
various  efforts  in  the  RSM  program.  Note  that,  in  this  figure,  several  different 
efforts  build  towards  a  product  outcome  that  will  be  transitioned  to  field  users. 
Steps  in  this  notional  diagram  are  sequential.  Outcomes  from  one  effort  gener¬ 
ally  contribute  to  and  support  a  subsequent  effort. 

However,  Figure  3,  which  provides  a  second  or  contrasting  example  of  outcome 
relationships,  shows  a  product  that  is  already  fielded.  In  this  illustration,  the 
outcomes  of  research  and  technology  development  efforts  are  adding  new  fea¬ 
tures  and  functions  to  this  product  over  time. 


*Within  Life  Cycle  Planning,  this  team  may  be  called  the  “Product  Development  Team,”  which  refers  to  a  special  type 
of  Project  Delivery  Team. 
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Example  I  Relationship  of  Outcomes 
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Figure  3.  Example  relationships  of  outcomes. 
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4  Publications  Product  Categories 

Introduction 

The  RSM  Program  will  target  its  publications  to  two  principal  audiences:  the 
research  and  user  communities.  There  are  several  venues  for  publications  re¬ 
sulting  from  research  in  the  RSM  Program:  official  USACE  publications,  ERDC 
publications,  journal  publications,  conference  publications,  and  miscellaneous 
publications.  Each  type  of  publication  is  described  in  greater  detail  below. 

USACE  Publications 

The  principal  audience  for  USACE  Publications  is  our  primary  user  community, 
the  Corps  Districts  and  Divisions.  USACE  publication  categories  include: 
(1)  Army  Pamphlets,  (2)  Army  Regulations  (3)  Army  Technical  Manuals, 
(4)  Engineer  Circulars,  (5)  Engineer  Design  Guides,  (6)  Engineer  Manuals, 
(7)  Engineer  Pamphlets,  (8)  Engineer  Regulations,  (9)  Engineer  Technical  Let¬ 
ters,  and  (10)  Miscellaneous  Publications.  The  RSM  Research  Program  will  pri¬ 
marily  author  the  following  formal  Corps-level  categories  of  publications: 

•  Engineer  Manuals  (EM) 

•  Engineer  Pamphlets  (EP) 

•  Engineer  Technical  Letters  (ETL) 

•  Technical  Instructions  (TI). 

Engineer  Publications  are  posted  to  the  World  Wide  Web  and  made  accessible 
through  URL: 

http://www.hnd.usace.armv.mil/techinfo/engpubs.htm 

Engineer  Manuals  (EM) 

An  Engineer  Manual  contains  technical  guidance  and  dir ective/non- directive  in¬ 
struction  criteria  of  a  continuing  nature  concerned  primary  with  engineering  and 
design  type  projects.  For  this  reason,  most  EMS  are  in  the  1110  (Engineering 
and  Design)  series.  Manuals  may  also  include  (as  appendixes)  additional  docu¬ 
ments  such  as  engineer  and  technical  instructions  in  which  a  division  chief  of  the 
proponent  office  has  the  authority  to  approve.  Manuals  may  not  be  supple¬ 
mented. 
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Engineer  Pamphlets  (EP) 

An  Engineer  Pamphlet  may  be  one  of  two  EP  types,  standard  (or  procedural)  and 
informational.  A  standard  EP  contains  functional  or  procedural  information,  in¬ 
structional  guidance  needed  to  implement  programs  or  systems  directed  in  regu¬ 
lations.  Procedural  pamphlets  may  include  the  appropriate  additional  docu¬ 
ments  (as  appendices).  Informational  pamphlets  are  nonpolicy  publications  that 
are  designed  for  information  only.  They  consist  of  booklets,  leaflets,  and/or  fold¬ 
ers  on  various  information,  recruitment  literature,  historical  studies,  and  refer¬ 
ence  texts.  The  format  varies.  It  is  dictated  at  the  proponent’s  discretion,  de¬ 
pending  on  the  type  of  information  it  contains.  Pamphlets  may  not  be 
supplemented. 

Engineer  Technical  Letters  (ETL) 

An  Engineer  Technical  Letter  contains  “advance”  information  on  design,  engi¬ 
neering  and  construction  projects.  ETLs  are  considered  intermediary  publica¬ 
tions  that  will  eventually  be  republished  in  more  permanent  media.  (They  will 
remain  active  for  no  more  than  5  years  from  the  date  of  issuance.)  The  expira¬ 
tion  date  will  be  positioned  immediately  above  the  series  title,  and  will  reflect 
the  last  day  of  a  quarter.  If,  after  5  years,  the  guidance  of  a  technical  letter  is 
still  valid,  it  must  be  republished  as  a  manual.  Technical  letters  cannot  be  used 
to  replace  regulations  or  circulars.  Technical  letters  may  not  be  supplemented. 

Technical  Instructions  (Tl) 

Technical  Instructions  are  documents  used  to  rapidly  provide  technical  instruc¬ 
tions  to  design  offices.  TIs  provide  design  and  construction  criteria,  and  apply  to 
all  U.S.  Army  Corps  of  Engineers  (USACE)  commands  having  military  construc¬ 
tion  responsibilities;  they  are  essential  communications  between  policy-making 
elements  and  execution  elements  within  each  of  the  various  technical  disciplines. 
TIs  are  “living  documents”  that  are  periodically  reviewed,  updated,  and  made 
available  to  users  as  part  of  the  Headquarters,  U.S.  Army  Corps  of  Engineers 
(HQUSACE)  responsibility  for  technical  criteria  and  policy  for  new  military  con¬ 
struction.  CEMP-ET  is  responsible  for  administration  of  the  TI  system.  Techni¬ 
cal  content  of  the  TI  is  the  responsibility  of  the  HQUSACE  element  of  the  disci¬ 
pline  involved. 


ERDC  SR-03-1 


31 


ERDC  Publications 

The  Engineer  Research  and  Development  Center  (ERDC)  regulation  25-30-1, 
“ERDC  Technical  Publishing  and  Printing”  (1  December  1999)  defines  eight 
categories  of  official  (numbered)  ERDC  reports:  (1)  Technical  Report,  (2)  Techni¬ 
cal  Note,  (3)  Miscellaneous  Paper,  (4)  Contract  Report,  (5)  Letter  Report,  (6)  Spe¬ 
cial  Report,  (7)  Monograph,  and  (8)  Brochure.  The  RSM  Program  will  primarily 
produce  publications  in  three  of  these  report  series,  and  in  one  additional  (pro¬ 
posed)  category: 

•  Technical  Reports  (TRs) 

•  Technical  Notes  (TNs) 

•  Miscellaneous  Papers  (MPs) 

•  Special  Reports  (SRs) 

•  Fact  Sheets. 

Each  publication  type  has  a  corresponding  electronic  Microsoft®  Word  template 
with  predefined  design,  page  layout,  and  electronic  styles.  Authors  may  use 
these  electronic  templates  to  compose  publications  in  draft  form.  Authored 
manuscripts  not  formatted  to  publication  specifications  will  be  reformatted  to 
meet  these  standards  before  final  publication.  ERDC  publication  templates  are 
posted  to  the  ERDC  Intranet  and  are  accessible  through  URL: 

https://iwww.cecer.army.mil/KD/ 

The  RSM  program  will  target  its  publications  to  two  principal  audiences:  the 
research  and  user  communities.  For  example,  TRs  and  SRs  (by  definition,  longer 
publications)  that  focus  on  technical  information  and  results  will  be  aimed  at  the 
research  community.  TRs  and  SRs  that  focus  on  documentation  and  other  user 
issues  should  be  written  to  satisfy  the  more  general  (less  technical)  user  audi¬ 
ence.  TNs  and  Fact  Sheets  (shorter  publications)  will  be  written  to  the  more 
general  “user”  community.  Definitions  of  each  publication  series  follow. 

Technical  Reports 

The  TR  series  is  the  normal  vehicle  for  reporting  the  detailed  processes  and  re¬ 
sults  of  research  projects,  i.e.,  to  document  sponsored  research  and  development 
that  has  been  completed  or  terminated.  Technical  Reports  have  specific  content 
requirements  for  Chapter  1  content,  and  must  also  include  a  formal  “Conclusion” 
chapter. 
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A  TR  Chapter  1  contains  these  sections: 

1.  Background  (required).  The  Background  should  include  a  problem  statement, 
explain  the  need  for  the  subject  research,  and  describe  its  relevance  to  the  Army. 

2.  Objective(s)  (required).  The  Objectives  must  include  a  clear  statement  of  the  ob- 
jective(s)  of  the  research,  which  may  (if  the  report  focuses  on  a  stage  of  work)  be 
stated  as  “overall”  and  “specific”  objectives. 

3.  Approach  (required).  The  Approach  delineates  the  actual  steps  taken  to  complete 
the  current  research. 

4.  Scope  (not  required).  The  Scope  section  describes  research  or  application  con¬ 
straints.  Researchers  may  use  this  section  to  ensure  that  the  results  of  their 
work  should  not  be  over-  (or  under-)  generalized,  or  that  (for  example)  users  un¬ 
derstand  specific  preliminary  hardware  or  software  requirements  of  software 
products. 

5.  Mode  of  Technology  Transfer  (required  in  “direct-funded”  research) .  The  Mode  of 
Technology  Transfer  (T2)  section  specifies  how  the  results  of  the  work  will  be 
transferred  “to  the  field”  (how  it  will  be  put  in  the  hands  of  actual  end  users) — 
through  product  distribution,  training,  secondary  publication,  or  by  its  contribu¬ 
tion  to  future  planned  research. 

Technical  Notes 

Technical  notes  may  contain  the  same  information  as  a  TR,  but  are  shorter  and 
more  focused,  generally  not  longer  than  10  to  12  pages.  Technical  notes  focus 
more  of  research  results  and  less  on  the  research  process,  but  may  also  include 
synopses  of  projects,  interim  reports  describing  the  early  phases  of  a  project  (i.e., 
before  there  are  enough  results  for  a  technical  report),  and  spin-off  results  of  a 
research  project  (i.e.,  interesting  results  that  should  be  reported,  but  that  are  not 
significant  enough  for  a  TR) . 

The  RSM  Research  Program  will  be  producing  a  series  of  TNs  designed  for  rapid 
transmission  of  technology  to  the  user  community.  RSM  TNs  will  generally  be  2- 
to  10-page  notes  that  identify  problem  areas  and  provide  techniques  or  data  for 
solutions  that  will: 

•  clarify  and  call  attention  to  relevant  methodology  and  procedures 

•  suggest  new,  improved,  or  expanded  methods  used  in  the  solution  of  RSM 
problems 

•  advise  of  procedures  undergoing  revision  and  identify  problem  areas 

•  disseminate  information  on  sources  of  data  and  unique  design  procedures  de¬ 
veloped  for  specific  problems 

•  promote  discussion  and  an  exchange  of  procedures  used  in  Corps  offices. 
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Miscellaneous  Papers 

This  category  is  for  journal  articles,  conference  papers,  book  chapters,  or  other 
shorter  works  that  are  published  outside  of  ERDC.  The  purpose  of  the  category 
is  to  track  these  publications  and  to  ensure  that  the  ERDC  and  Corps  libraries 
get  copies.  Miscellaneous  publications  will  address  both  the  research  community 
and  the  user  community. 

Conference  Publications 

Conference  publications  will  address  both  the  research  community  and  the  user 
community.  Conferences  are  a  valuable  tool  for  information  exchanges  with  end 
users  as  well  as  researchers  from  outside  ERDC.  Collaborations  arising  from 
relationships  formed  at  conferences  have  often  enhanced  ERDC  research  and 
development.  Research  results  published  in  peer-reviewed  conference  proceed¬ 
ings  are  important  in  the  development  of  legally  defensible  engineering  theories 
and  practices. 

Journal  Publications 

Journal  papers  are  refereed  publications  in  journals  of  professional  or  technical 
societies,  and  as  such,  address  both  the  research  and  the  user  communities. 
Publication  of  journal  papers  is  an  important  factor  in  providing  wide  public  dis¬ 
semination  of  research  and  development  results.  Journal  papers  provide  an  ar¬ 
chival  record  of  research  important  in  the  development  of  legally  defensible  en¬ 
gineering  theories  and  practices. 

Special  Report 

Special  reports  are  those  that  do  not  fit  well  elsewhere,  but  should  be  included  in 
a  numbered  series  to  track  these  publications  and  to  ensure  that  the  library  gets 
copies.  Special  reports  will  address  both  the  research  community  and  the  user 
community.  Special  reports  may  include  conference  proceedings  and  abstracts, 
ADP  reports,  instruction  reports,  reports  that  primarily  present  data,  computer 
program  listings,  and  literature  reviews  or  bibliographies. 

Fact  Sheets 

Fact  Sheets  are  short  (no  more  than  two  sides)  informational  write-ups,  written 
to  a  general  audience,  and  intended  to  stimulate  interest  in  a  product,  facility, 
capability  or  service,  or  area  of  research.  Fact  sheets  should  always  guide  the 
reader  to  the  actual  “hands-on”  product,  to  an  actual  facility  location,  to  web 
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sites,  documentation,  training,  and/or  to  laboratory  points  of  contact  who  can 
provide  further  information  on  the  described  topic. 


Conclusion 

The  publications  series  described  here  can  meet  a  broad  range  of  reporting, 
documentation,  and  marketing  purposes.  A  given  project  may  use  a  single  publi¬ 
cation  type  to  meet  its  reporting  needs.  On  the  other  hand,  each  of  the  four  pub¬ 
lications  series  may  be  seen  as  complementary,  rather  than  exclusive  categories. 
An  individual  project  or  work  unit  may  produce  more  than  one  type  of  publica¬ 
tion.  A  Technical  Report  may,  for  example,  be  accompanied  by  a  companion 
Technical  Note  or  Fact  Sheet  describing  the  same  area  of  research  as  a  way  of 
meeting  interim  reporting  requirements,  as  a  way  of  addressing  a  wider  audi¬ 
ence,  or  as  a  way  of  meeting  the  dual  needs  of  technical  documentation  and 
product  marketing.  All  unclassified  ERDC  publications  are  posted  to  the  World 
Wide  Web  and  made  accessible  through  URL: 

http://libweb.wes.army.mil/index.htm 
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5  Technology  Transfer  Planning 

Introduction 

Technology  transfer  has  long  been  a  challenge  for  the  U.S.  Army  Corps  of  Engi¬ 
neers  (USACE)  and  its  Research  and  Development  (R&D)  community.  The  R&D 
community  has  developed  several  technologies  and  products  that  have  been 
transferred  into  use  by  only  a  handful  of  users.  Some  other  technologies  have 
received  widespread  use.  The  USACE  Engineer  Research  and  Development 
Center  (ERDC)  needs  to  improve  its  ability  to  work  with  technology  proponents 
and  users  to  ensure  technology  transfer  occurs.  This  chapter  outlines  some  con¬ 
cepts  associated  with  successful  technology  transfer  and  proposes  a  planning 
framework  for  increasing  the  likelihood  of  future  success  in  the  Army. 


Lessons  From  Commercial  Approaches 

Unlike  the  Government  sector,  successful  commercial  businesses  tend  to  be  very 
successful  at  marketing  or  transferring  their  technology  products  into  use.  The 
American  Marketing  Association  defines  marketing  as  the  “process  of  planning 
and  executing  the  conception,  pricing,  promotion,  and  distribution  of  goods,  ser¬ 
vices,  and  ideas  to  create  exchanges  with  target  groups  that  satisfy  end  user  and 
organizational  objectives.”  This  is  basically  what  technology  transfer  is  all  about 
—  putting  technologies  in  the  hands  of  users  for  their  benefit.  By  doing  so  effi¬ 
ciently,  USACE  and  ERDC  will  meets  its  organizational  goals  of  improving  its 
end  users  productivity  or  well  being  via  technology  development  and  delivery. 

Large  commercial  businesses  such  as  Microsoft,  Intel,  and  Ford  Motor  Company 
have  a  well-established  process  for  marketing  or  transferring  their  technologies 
and  products  to  users.  Businesses  such  as  these:  (1)  conduct  market  research  to 
identify  consumer  needs  and  preferences;  (2)  they  develop  products  to  meet  those 
requirements;  and  then  (3)  apply  proven  methodologies  to  effectively  promote, 
package,  price,  and  distribute  their  products  to  consumers.  As  the  lifeblood  of  a 
commercial  business  is  revenue  generated  by  the  sale  of  products,  it  dedicates 
the  necessary  resources  and  hires  trained  personnel  to  effectively  plan  and  exe¬ 
cute  the  marketing  of  its  products. 
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The  Army  and  USACE  attempts  to  define  user  technology  needs  through  the 
Army’s  Research,  Development,  Testing,  and  Evaluation  (RDT&E)  program. 
RDT&E  funding  lines,  which  provide  a  resource  base  for  product  development. 
These  funding  lines  are  limited  to  basic  research  and  applied  research  activities 
and  are  not  available  for  use  in  demonstration  or  technology  transfer  activities. 
These  activities  could  be  improved  with  more  effective  involvement  of  both  head¬ 
quarters  level  technology  proponents  and  the  ultimate  users  of  the  technologies 
under  development. 

Currently,  the  USACE  R&D  community  has  varying  approaches  to  the  third 
marketing  activity — the  promotion,  packaging,  and  distribution  of  its  technolo¬ 
gies.  In  some  research  areas,  technical  assistance  programs  such  as  the  Dredg¬ 
ing  Operations  Technical  Support  (DOTS),  Water  Operations  Technical  Support 
(WOTS),  and  Wetlands  Regulatory  Assistance  Program  (WRAP)  programs  do 
provide  some  support,  particularly  in  distribution  of  technologies.  In  other  re¬ 
search  areas,  no  promotion,  packaging,  and  distribution  is  supported.  Nor  does 
the  USACE  R&D  community  currently  systematically  plan  for  the  transfer  of  its 
technology.  This  planning  function  should  be  done  by  proponent  organizations 
that  would  sponsor  and  ensure  funding  is  available  to  support  the  use  of  the 
technology  among  its  constituent  users.  The  R&D  community  should  support 
this  planning  effort.  The  Internet  and  e-commerce  principles  have  become  a  ma¬ 
jor  tool  to  support  planning  efforts  to  infuse  technology. 

Another  key  to  successful  technology  transfer  that  has  been  overlooked  by  the 
R&D  community  and  proponents  alike  is  the  challenge  of  getting  an  organization 
ready  to  implement  a  new  technology.  Much  has  been  written  in  organizational 
literature  about  managing  change.  Implementing  new  technology  in  an  organi¬ 
zation  must  be  a  well  organized  and  planned  effort  complete  with  proper  man¬ 
agement  emphasis,  resourcing,  training,  and  revised  business  practices  to  ac¬ 
quire  and  implement  a  new  technology.  Proponents  are  in  a  key  role  to  ensure 
the  changes  associated  with  technology  implementation  are  addressed  in  any 
technology  transfer  plan. 

Successful  technology  transfer  requires  strong  proponency  to  ensure  the  technol¬ 
ogy  is  developed  to  effectively  support  existing  or  planned  business  practices,  the 
implementation  is  properly  planned  and  executed,  and  organizations  are  prop¬ 
erly  prepared  to  implement  a  technology.  Adequate  resources  must  be  available 
throughout  the  life  cycle  of  this  technology  development  and  implementation  ef¬ 
fort. 
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Technology  Development 

Identification  of  Future  Operational  Capabilities  (FOC)  and  Requirements 

Success  at  technology  transfer  is  much  easier  for  a  technology  that  meets  a  true 
need  of  the  user  community.  Successful  businesses  focus  research  and  develop¬ 
ment  investment  on  technologies  that  offer  the  greatest  likelihood  of  commercial 
success.  Identifying  future  technology  needs  requires  the  active  participation  of 
end  users. 

Within  the  Army,  the  ERDC  has  two  major  categories  of  users — proponents  and 
users.  Each  will  provide  their  unique  perspectives  in  defining  future  technology 
needs  and  must  be  involved  in  the  identification  of  future  technology  needs.  Pro¬ 
ponents  typically  provide  the  long-range  vision  for  how  the  Army  needs  to  oper¬ 
ate  in  the  future.  Proponents  have  the  ultimate  responsibility  for  ensuring  the 
technology  exists  to  support  that  future  operational  vision  and  to  plan  for  the 
transfer  of  the  technology  into  daily  use.  Users  provide  valuable  perspective  on 
existing  or  future  business  practices  and  how  technology  would  impact  those 
practices. 

Future  Operational  Capabilities  (FOCs)  are  intended  to  identify  future  business 
practices  and  the  associated  technology  required  to  support  those  practices. 
Both  proponents  and  users  need  to  participate  in  the  development  and  validation 
of  FOCs.  Once  FOCs  have  been  identified,  Army  technology  proponents  need  to 
work  closely  with  the  R&D  community  throughout  the  development  and  transi¬ 
tion  effort  to  ensure  success. 

User  Input  to  Technology  Development 

Technologies  must  be  developed  to  be  compatible  with  and  support  existing  or 
planned  existing  business  practices.  The  R&D  community  must  be  closely 
aligned  with  the  actual  users  of  the  technology  and  collect  input  from  them 
throughout  the  development  process.  Proponents  may  be  too  far  removed  from 
the  daily  business  operations  to  understand  the  impact  of  technology  on  daily 
operations.  User  groups  consisting  of  representatives  of  a  broad  spectrum  of  us¬ 
ers  should  be  formally  established  to  provide  such  input.  Formal  user  groups 
should  also  be  employed  for  technology  opportunities.  In  this  case,  innovative 
technologies  often  appear  that  will  shape  existing  or  create  future  business  prac¬ 
tices  in  ways  not  currently  recognized.  Proponents  and  users  need  to  work  with 
the  R&D  community  to  define  these  business  practices  in  light  of  these  technol¬ 
ogy  opportunities. 
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Demonstration  and  Operational  Testing 

The  field  demonstration  is  a  key  element  in  the  overall  transfer  of  the  technol¬ 
ogy.  The  demonstration  is  the  first  attempt  to  show  the  effectiveness  of  the 
technology  before  Army- wide  users.  The  focus  of  the  demonstration  should  be  on 
how  the  user  implements  and  benefits  from  the  technology.  Whether  or  not  a 
technology  works  should  be  proven  earlier  via  bench  tests  or  field  tests.  The 
demonstration  should  identify  operational  problems  facing  users  resulting  from 
its  implementation  and  use  that  will  inhibit  technology  infusion  efforts.  The 
demonstration  should  be  conducted  without  heavy  involvement  of  R&D  person¬ 
nel. 

Information  from  the  demonstration  is  critical  to  the  technology  infusion  plan¬ 
ning  effort  described  next.  The  demonstration  provides  an  opportunity  to  iden¬ 
tify  the  effectiveness  of  documentation  and  instructional  materials  and  what 
type  of  technical  support  will  be  necessary.  A  successful  demonstration  will  pro¬ 
duce  information  on  cost  of  implementation  and  savings  achieved  from  its  use 
that  should  be  highlighted  in  promotional  efforts. 

User  Validation 

As  a  result  of  the  demonstration  process,  users  and  proponents  need  to  validate 
the  benefits  and  the  need  for  implementing  the  technology  among  the  various 
users  in  the  Army.  The  operational  validation  and  results  of  the  demonstration 
become  proof  of  the  usefulness  of  the  technology  and  the  need  to  move  forward 
with  implementation.  Proponents  need  to  step  up  and  visibly  show  their  support 
for  implementation  before  the  broader  user  community. 


Technology  Infusion  Planning 

Technology  infusion  plans  as  defined  here  are  a  series  of  activities  that  must  be 
implemented  to  deliver  a  technology  to  potential  users.  Consequently  the  im¬ 
plementation  of  these  activities  must  be  planned,  scheduled,  and  assigned  to  in¬ 
dividuals  for  completion.  These  planning  activities  consist  of:  documentation; 
packaging,  pricing  and  distribution;  promotion;  training;  technology  support;  and 
promotion.  Without  each  of  these  activities  in  place,  it  will  be  difficult  to  suc¬ 
cessfully  transfer  technology  to  the  users.  Figure  4  shows  a  sample  technology 
transfer  “thumbnail”  plan.  This  thumbnail  plan  incorporates  many  of  the  issues 
involved  in  technology  transfer  planning  discussed  here.  Such  a  thumbnail  plan 
should  be  developed  during  the  technology  development  stage  early  in  the  prod¬ 
uct  life  cycle  process  to  identify  potential  technology  transfer  issues. 
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Technology  Transfer  “Thumbnail” 

Research  Program:  Regional  Sediment  Management 

Product: 

Work  Unit  Number: 

Thumbnail  Date: 

Product  Introduction  Date: 

ERDC  Project  Manager: 

HQ  Proponent: 

Product  Description: 


Infusion  Plan 


Documentation: 

Funding:  Source: 

Completion  Date: 

POC: 

Packaging/Distribution : 

Funding:  Source: 

Completion  Date: 

POC: 

Promotion: 

Funding:  Source: 

Completion  Date 

POC: 

Training: 

Funding:  Source: 

Completion  Date 

POC: 

User  Support: 

Funding:  Source: 

Completion  Date 

POC: 

Implementation  Issues/Strategies 

Organization  Change 
Business  Processes 
Resource  Allocation 
IT  Infrastructure 

Technology  Upgrade  &  Maintenance 


Figure  4.  RSM  technology  transfer  “thumbnail. 
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Responsibility  for  implementing  the  various  activities  within  the  implementation 
mix  will  most  likely  fall  upon  many  different  people  and  organizations.  Army 
technology  proponents  responsible  for  implementing  the  overall  technology 
transfer  plan  must  ensure  that  individuals  with  responsibilities  understand 
their  roles  and  the  schedule  in  which  the  duties  must  be  performed.  Proponents 
must  also  ensure  that  adequate  financial  and  personnel  resources  are  available 
to  support  the  activities  of  the  technology  infusion  plans. 

Funds  to  support  the  oversight  and  management  of  technology  transfer  activities 
need  to  be  identified  and  budgeted  for.  Some  of  these  costs  may  be  paid  for  out  of 
normal  operating  expenses  for  organizations  involved  in  technology  transfer 
planning.  Technology  transfer  planning  costs  could  be  supplemented  by  charg¬ 
ing  end  users  a  price  for  acquiring  the  technology.  Additional  costs  will  be  born 
by  organizations  implementing  the  technology.  Technology  transfer  plans 
should  identify  estimates  for  both  types  of  costs. 

Documentation 

Documentation  consists  of  instructional  materials  to  be  included  with  the  tech¬ 
nology  and  guidance  documents  that  authorize  the  use  of  the  technology.  Formal 
Army  guidance  documents  such  as  guide  specifications  or  technical  manuals  are 
critical  to  the  acceptance  of  the  technology  by  the  user.  While  not  usually  part  of 
the  technology  package  that  is  distributed  to  users,  it  nevertheless  supports  the 
use  of  the  technology  by  the  field.  In  some  cases — such  as  new  procedures — 
these  documents  may  be  the  only  way  such  technologies  are  delivered  to  users. 
Revisions  to  formal  Army  technical  documents  to  include  the  technology  typi¬ 
cally  can  take  years  to  complete.  Interim  guidance  can  be  provided  through  En¬ 
gineering  Technical  Letters  or  letters  of  authorizations  accompanied  by  technical 
information  such  as  user  guides.  These  documents  and  later  updates  can  be 
made  available  via  the  Internet. 

Packaging,  Pricing,  and  Distribution 

Packaging  refers  to  how  the  technology  will  be  assembled  for  distribution  and 
use  by  the  user.  Packaging  includes  instructional  materials  to  be  included  with 
the  technology.  Technology  transfer  costs  could  be  supplemented  by  charging 
end  users  a  price  for  acquiring  the  technology.  Distribution  refers  to  the  logistics 
of  getting  a  technology  from  a  provider  of  the  technology  to  a  user.  Technologies 
are  typically  shipped  through  the  mail  or  freight  services,  or  delivered  person¬ 
ally.  A  single  distribution  point  is  recommended  to  avoid  confusion  among  po¬ 
tential  users.  Distribution  centers — whether  they  be  government  or  commer- 
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cial — need  to  be  staffed  adequately  to  ensure  responsiveness  to  user  requests. 
The  Internet  has  now  become  a  major  medium  to  distribute  software  and  docu¬ 
mentation  supporting  its  use.  Online  orders  and  payments  for  acquiring  tech¬ 
nologies  is  now  a  common  e-business  practice. 

Training 

Some  technologies  may  be  more  complicated  to  learn  than  others.  Instructional 
material  included  with  the  technology  may  only  serve  to  get  the  user  started  on 
applying  the  technology  on  a  limited  basis.  Advanced  training  may  need  to  be 
developed  to  further  the  user’s  knowledge  of  the  more  specific  applications  of  the 
technology.  Special  training  courses  may  also  need  to  be  developed  for  different 
types  of  users  of  the  same  technology.  For  example,  individuals  responsible  for 
designing  a  heating  control  system  into  a  building  would  need  different  training 
than  those  responsible  for  operating  the  controls  later  on.  The  scheduling  of 
training  should  coincide  with  goals  of  how  quickly  the  technology  should  be 
adopted  by  users.  Online  learning  and  remote  training  via  the  Internet  is  now  a 
proven  alternative  to  traditional  classroom  learning. 

Technology  Support 

Users  will  inevitably  have  questions  or  need  some  type  of  assistance  in  imple¬ 
menting  a  technology.  Some  organization  or  individual  must  be  readily  available 
to  assist  users.  The  staffing  of  this  central  source  of  assistance  and  the  services 
it  provides  will  vary  depending  on  the  nature  of  the  technology  and  the  expected 
need  for  assistance.  Typically,  such  a  center  should  be  able  to  assist  users  with 
questions  over  the  phone,  conduct  onsite  visits  to  assist  with  technology  prob¬ 
lems,  and  provide  them  with  updates  or  new  information  on  the  product.  Chat 
rooms  or  online  support  centers  via  the  Internet  are  e-commerce  business  prac¬ 
tices  that  should  be  applied  in  conjunction  with  traditional  methods. 

Promotion 

Promotion  activities  are  designed  to  inform  and  motivate  potential  users  to  pro¬ 
cure  and  implement  a  technology.  Promotion  activities  should  generate  an 
awareness  of  the  existence  of  a  new  technology  among  potential  users,  provide 
information  on  its  uses  and  benefits,  and  identify  procedures  and  sources  of  as¬ 
sistance  for  obtaining  the  technology  and  related  services.  The  ultimate  goal  is 
to  provide  information  to  assist  the  user  in  making  a  decision  to  acquire  the 
technology.  The  timing  of  promotion  activities  typically  should  not  precede  the 
establishment  of  mechanisms  to  distribute  and  support  the  technology.  A  criti¬ 
cal  component  of  promotional  planning  is  defining  the  target  audience  for  the 
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promotional  activities.  Different  promotional  efforts  and  messages  should  be 
implemented  for  each  of  these  audiences.  Repetitive,  quality  messages  are  criti¬ 
cal  to  ensure  adequate  reach  and  frequency  is  achieved  among  the  target  end  us¬ 
ers.  The  technology  proponents  and  ERDC  need  to  establish  a  program  for  sus¬ 
taining  the  promotion  of  available  technologies  and  support  services  using  both 
Internet  communication  tools  and  traditional  media. 


Preparing  the  Organization  To  Adopt  a  Technology 

The  technology  infusion  environment  can  be  thought  of  as  a  complex  nexus 
where  organizational  culture,  business  processes,  resource  allocation  and  infor¬ 
mation  technology  infrastructure  co-exist  to  facilitate  or  pose  barriers  to  the  ad¬ 
aptation  of  technological  innovation.  It  seems  that  the  readiness  of  the  following 
four  elements  are  necessary  to  facilitate  a  successful  technology  infusion  to  the 
end  users: 

1.  Organization  and  culture  readiness 

2.  Business  process  readiness 

3.  Resource  allocation  readiness 

4.  Information  technology  infrastructure  readiness. 

Change  management  concepts  and  practices  should  be  applied  to  adequately 
prepare  an  organization  to  implement  a  new  technology.  The  change  manage¬ 
ment  effort  should  focus  on  addressing  these  four  barriers  to  technology  infusion. 

Organization  and  Culture  Readiness 

The  first  critical  element  is  Organizational  and  Cultural  Readiness  for  Techno¬ 
logical  Innovation.  A  culture  that  has  inflexible  regulations  or  otherwise  en¬ 
courages  risk  avoidance  can  result  in  severe  barriers  to  technology  infusion. 
New  technology  that  conflicts  with  widespread  cultural  values  may  be  rejected. 
For  example,  if  the  general  tendency  of  a  culture  is  that  items  are  disposable, 
recycling  may  be  not  be  successful.  Fear  of  liability  may  encourage  conservative 
approaches  and  it  may  be  difficult  to  set  up  field  demonstrations.  Successful 
technology  infusion  requires  methods  to  overcome  such  organizational/cultural 
barriers  to  be  so  that  the  Corps  of  Engineers  and  the  Army  can  benefit  from 
daily  use  of  technological  innovation. 

Business  Process  Readiness 

The  second  critical  element  is  Business  Process  Readiness  for  Technology  Infu¬ 
sion.  If  a  new  technology  is  delivered  when  old  business  processes  inhibit  or  in- 
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terfere  with  the  implementation  of  new  technology,  it  will  be  impossible  to  gain 
the  benefits  of  this  technology  infusion.  This  technology  will  be  stored  on  a  shelf 
rather  than  used.  A  number  of  technologies  developed  as  a  result  of  the  Corps  of 
Engineers  R&D  program  could  be  described  this  way.  For  example,  when  a 
module  of  Engineered  Management  System  (EMS)  is  delivered,  the  business 
process  is  not  changed  to  obtain  the  maximum  benefit  of  the  EMS,  but  it  is  im¬ 
posed  onto  the  end  user  to  use  it  within  old  business  process  constraints.  This 
may  not  encourage  people  who  could  potentially  benefit  from  this  because  it  is 
difficult  to  fit  the  new  technology  into  the  old  business  process.  Army  recom¬ 
mends  PAVER  as  an  option,  but  Air  Force  is  using  the  PAVER  differently  be¬ 
cause  the  process  was  changed  to  require  PAVER  analysis  in  requesting  airfield 
maintenance  funds.  So  it  is  important  to  consider  changing  the  business  proc¬ 
ess,  including  the  type  of  training  needed,  when  a  new  technology/system  is  de¬ 
livered  to  a  user  community. 

Resource  Allocation  Readiness 

The  third  critical  element  is  Resource  Allocation  Readiness  for  Technological  In¬ 
novation  to  help  ensure  availability  of  an  appropriate  amount  of  dollars  to  sup¬ 
port  the  life  cycle  management  of  a  new  technology.  We  read  of  many  cases 
where  new  computer  systems  were  not  implemented  and  supported  successfully 
due  to  financial  problem  and  these  systems  being  dropped  as  failure.  A  sound 
financial  plan  for  the  life  cycle  management  of  a  new  technology  is  necessary  to 
produce  successful  technology  infusion.  It  is  mandatory  to  have  not  only  a  finan¬ 
cial  plan,  but  also  the  commitment  of  leadership  to  provide  the  necessary  re¬ 
sources  at  the  time  needed,  not  a  few  years  later.  Without  actual  dollars  to  sup¬ 
port  life  cycle  management  of  a  new  technology,  any  technology  infusion  cannot 
be  successful.  However,  it  is  not  clear  how  to  obtain  the  commitment  before  the 
technology  is  completed  for  delivery.  Even  though  there  is  an  LCMIS  regulation 
for  all  information  system  development,  lack  of  funding  for  the  life  cycle  seems  to 
be  one  of  the  most  frequent  reasons  for  not  achieving  the  level  of  success  ex¬ 
pected  from  new  technologies.  An  organization  planning  to  adapt  a  new  technol¬ 
ogy  must  perform  an  analysis  that  considers  the  cost  of  operations  and  mainte¬ 
nance,  cost  of  system  upgrade,  and  the  cost  of  training  users  and  support 
personnel. 

Information  Technology  Infrastructure  Readiness 

The  fourth  critical  element  is  Information  Technology  (IT)  Infrastructure  Readi¬ 
ness  for  Technological  Innovation.  With  rapid  advances  in  information  technol¬ 
ogy,  a  major  contributing  factor  to  new  infrastructure  technology  development  is 
information  technology.  Often  new  technologies  are  developed  under  the  as- 
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sumption  that  end-users  will  have  a  certain  IT  infrastructure.  Yet  many  users 
may  not  have  the  correct  IT  infrastructure  to  use  the  new  technology  when  it  is 
ready  for  delivery,  limiting  the  benefit  of  this  technology  to  only  those  with  IT 
infrastructure  readiness.  Therefore,  it  is  necessary  to  consider  IT  infrastructure 
readiness,  as  an  essential  element,  when  a  new  technology  is  being  developed 
and  getting  ready  to  be  delivered.  For  example,  an  IT  platform,  communication 
lines,  operating  systems,  and  data  structure  need  to  be  considered  together  as 
well  as  application  architecture. 
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6  Conclusions 


The  concepts  proposed  in  this  report  are  intended  to  improve  life  cycle  planning 
approaches  and  infusion  success  from  USACE  research  investments.  The  au¬ 
thors  recommend  that  the  concepts  proposed  in  this  report  be  tested  within  RSM 
and  other  associated  research  programs  (e.g.,  TOWNS,  SMART)  and  then  evalu¬ 
ated,  modified  and  verified  before  they  are  adopted  by  broader  USACE  research 
and  technology  communities  of  interest.  However,  these  recommended  concepts 
for  Product  Life  Cycle  enhancements  are  intended,  eventually,  for  all  of  USACE. 

Because  of  this  broad  scope,  the  technology  life  cycle  is  viewed  here  from  the 
USACE/ Army  perspective,  with  research  fitting  into  this  perspective  as  only  one 
possible  course  of  action  that  might  be  considered  as  a  result  of  a  technology  re¬ 
quirement  or  opportunity.  Other  courses  of  action  might  be  to  simply  acquire 
existing  off-the-shelf  capabilities,  to  acquire  service  support  from  a  provider,  or 
to  adopt  a  capability  already  in  use  by  another  organization/agency. 

Viewing  research  outcomes  as  a  component  of  the  technology  life  cycle  does  fa¬ 
cilitate  connecting  research  with  our  USACE  processes.  Thus,  a  key  to  our  rec¬ 
ommended  concepts  is  linkages  to  the  USACE  Project  Management  Business 
Process  (PMBP),  to  the  Science  and  Engineering  Technology  (SET)  initiative, 
and  to  the  emerging  USACE  Technical  Architecture.  Our  cornerstones  of  change 
include  the  following  three  major  areas: 

•  use  of  standard  outcome  types  and  transition  plans 

•  teaming  for  success  through  the  use  of  PMBP  approaches  in  the  product  life 
cycle  process 

•  use  (and  shaping  of)  the  emerging  technical  architecture  for  IT-based  product 
outcomes. 

These  three  approaches,  if  followed,  should  greatly  improve  the  infusion  success 
from  our  research  investments,  and  enhance  the  linkages  between  USACE  tech¬ 
nology  plans  and  research  outcomes. 
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